Enhancing processes within rigidly designed software can be challenging. System integrators and software vendors conventionally design systems with current enterprise needs in mind, and without regard to potential modifications. Consequently, the systems tend to be inflexible. This is particularly true for database applications. The original design of a database schema dictates what actions the application can perform. This type of database schema design leaves little room for future enhancement.
Two approaches are conventionally used to address the above stated problem of database enhancement. One approach is conventionally provided by the software, itself. The software may have the ability to send messages that regard application actions to other applications for analysis. For example, WebSphere® Commerce Suite, available from International Business Machines Corporation (IBM), has the ability to send a message with regard to detailed purchase order information. This message may then be sent to an enterprise resource planning system or a customer relationship management system for analysis and possible further action.
Software developers can provide the second approach. Specifically, developers can create triggers within the software application according to the expected needs of the enterprises. Triggers are procedures, or sets of Structured Query Language (SQL) statements that are stored in a database. Originally developed by IBM, SQL provides an interface with which to make queries into databases. The triggers are executed, or fired, when a table is modified. Triggers are powerful tools that may be used to perform many tasks, such as restricting access to specific data, logging, or auditing of data sets. A trigger is activated whenever a specified event, such as an insert, delete, or update event, occurs on a particular table. As such, a trigger consists of an event (an INSERT, DELETE, or UPDATE statement issued against an associated table) and an action (the related procedure). Also, triggers have an activation time, such as before, after, or instead of the triggering event. Triggers are used to preserve data integrity by checking on or changing data in a consistent manner.
Using this second approach, developers are required to allocate large amounts of time to understand the relationship between application actions and the data persistency within the associated database(s). This is particularly true where a programmer at the user level desires to modify a preprogrammed trigger. Any such modification requires the user to code the adapted trigger characteristics into each trigger. This approach is very time consuming and relies heavily on the developer's database skills and understanding of database table relationships. Third party software packages that can create and use triggers often cannot be modified, at all. The users generally do not have access to the propriety source code.
As a result, enterprises with changing process needs are forced to go back to the system integrator or software vendor to request a redesign of the database schema to change triggering capabilities, or to hire database experts to thoroughly analyze the database schema to discover triggers scenarios. Both of these options create large expenditures for the enterprise and cause decreased productivity due to delayed system modifications.
Therefore, there exists a need for an improved manner of modifying database trigger behavior for software applications.